The invention concerns Internet Protocol (IP) communication networks, and more precisely the compression and/or decompression of data of IP packets of streams that communication equipments exchange within such networks.
Here “IP communication network (or IP network)” means any type of network having an access network (where applicable a radio access network) capable of transmitting data in the form of cells, for example of ATM (Asynchronous Transfer Mode) type, on a transport medium, for example of the TCP/IP or UDP/IP type. ATM cells are the result of decomposition (or segmentation) of packets of data, for example of IP type, and those packets (here IP packets) comprise an IP header, a header specific to the transport medium (for example UDP or TCP) and payload data. The IP network can in particular be a satellite network, for example a DVB-RCS (Digital Video Broadcasting-Return Channel System) network, providing Internet access via satellite, or an SDMB (Satellite Digital Multimedia Broadcast) network, or a terrestrial network, for example a cable (xDSL) network or a mobile or cellular network (GPRS/EDGE, or UMTS (where applicable of the MBMS (Multimedia Broadcast/Multicast Services) type, or the evolution of the UMTS known as LTE (Long Term Evolution), or DVB-H (Digital Video Broadcasting—Handhelds)), or a hybrid (satellite and terrestrial) network.
Generally speaking, the invention applies to any unit (or terminal) that has to send cells (where applicable of ATM type) on the AAL5 layer and in time slots allocated by another remote allocation control unit (for example a gateway or a hub). In fact it is a question here of reducing the number of cells to be sent, which number depends on the size of the data and the headers of protocol(s) utilizing the UDP/IP and TCP/IP layers.
Moreover, here “communication equipment” means any fixed or mobile (or portable or cellular) communication equipment capable of exchanging data by cable or by waves with another equipment, via an access network (where applicable a radio access network). Consequently, it can be, for example, a question of a fixed or mobile (or cellular) telephone, a fixed or portable computer, or a satellite gateway.
As the person skilled in the art knows, to transmit payload data in IP networks the data is integrated into IP packets comprising at least two headers (one of IP type (generally containing 20 bytes), the other of UDP or TCP type (generally containing 20 bytes), or IGMP, ICMP, DNS or SNMP type, for example). In some cases, for example in the presence of satellite transmission on a TCP medium (known as “T/TCP”) necessitating an option field (typically of at least 8 bytes), it is also necessary to add thereto a third header known as the “AAL5 trailer” (containing 8 bytes) in order to terminate the AAL5 layer of fragmentation into cells (for example of ATM type).
For a standard TCP acknowledgement without options, 40 bytes (20 bytes for IP and 20 bytes for the TCP acknowledgement) are necessary to fit exactly into the portion reserved for the payload data of a fixed and delimited ATM cell of 48 bytes under AAL5 including the AAL5 trailer of a byte (40+8=48).
For transmission via satellite, it is further necessary to add a T/TCP “option” field of at least 1 byte (and more typically 8 bytes), which totals 56 bytes (20+20+8+8=56), which cannot fit into one ATM cell and therefore necessitates two ATM cells (one containing 48 bytes (20 (IP)+20 (TCP)+8 (options)) and the other containing 8 bytes to describe the trailer of the AAL5 PDU (Packet Data Unit).
For networks in which the assignment of sending locations of cells to be sent (where applicable ATM cells) is a rare and costly resource, it is clear that two cells are then necessary rather than one (a factor of 2 applies to the usable bandwidth because of the “option” field). Generally speaking, if N is the number of initial cells and N−1 the number of final cells after compression, the compression gain is given by the ratio N−1/N, which is highly significant in the case of small packets.
Thus when IP packets are segmented into cells, each cell must comprise the headers of the IP packet from which it comes, the consequence of which is to reduce very significantly the ratio between the payload data transported and the associated header data, and therefore to monopolize a large quantity of resources. This is a particularly severe penalty if the IP network uses an access network the resources whereof are rare and generally costly, for example in the case of a satellite network. Unless otherwise indicated, the expression “header of an IP packet” when used hereinafter means both the IP header and the header of the transport protocol (for example UDP or TCP).
In order to reduce the amount of data to be transmitted, compression techniques can be used at the same time. Thus the ZIP technique can be used, for example. To compress the headers, techniques such as the Van Jacobson, IPHC (RFC 2508) or ROHC (RFC 2509) techniques can be used, for example. However, these techniques are very complex to implement because of their highly generic character and lead to compression of the TCP/IP headers and its T/TCP satellite option. In fact, these techniques are primarily concerned with reducing the size of the TCP/RTP/UDP/IP headers to be sent on a channel but without considering whether this size of headers and the size of the payload data will together occupy N or N−1 containers (here N or N−1 cells).
Moreover, the encoding of the fields to be compressed being based primarily on the difference of the headers to be sent, it is then necessary to use delicate restart mechanisms for TCP the performance whereof in degraded mode (loss of message) is considerably reduced via a satellite access network (major impact on the round trip time).
Moreover, known header compression techniques are applied regardless of the type of header, and thus regardless of the lifetime of the stream to which the header belongs, which can consume computation (CPU) resources unnecessarily.
Finally, the known header compression techniques generally take no account of the availability of computation (CPU) resources and/or local and remote memory resources, which is a problem for low-cost communication equipments (such as mobile or portable terminals, where applicable with satellite access).
No known solution proving entirely satisfactory, an object of the invention is therefore to improve upon this situation.